Content delivery networks (CDNs) have greatly improved the way content is transferred across data networks such as the Internet. A CDN accelerates the delivery of content by reducing the distance that content travels in order to reach a destination. To do so, the CDN strategically locates surrogate origin servers, also referred to as caching servers or edge servers, at various points-of-presence (POPs) that are geographically proximate to large numbers of content consumers and the CDN utilizes a traffic management system to route requests for content hosted by the CDN to the edge server that can optimally deliver the requested content to the content consumer. Determination of the optimal edge server may be based on geographic proximity to the content consumer as well as other factors such as load, capacity, and responsiveness of the edge servers. The optimal edge server delivers the requested content to the content consumer in a manner that is more efficient than when origin servers of the content publisher deliver the requested content. For example, a CDN may locate edge servers in Los Angeles, Dallas, and New York. These edge servers may cache content that is published by a particular content publisher with an origin server in Miami. When a content consumer in San Francisco submits a request for the published content, the CDN will deliver the content from the Los Angeles edge server on behalf of the content publisher as opposed to the much greater distance that would be required when delivering the content from the origin server in Miami. In this manner, the CDN reduces the latency, jitter, and amount of buffering that is experienced by the content consumer. The CDN also allows the content publisher to offload infrastructure, configuration, and maintenance costs while still having the ability to rapidly scale resources as needed. Content publishers can therefore devote more time to the creation of content and less time to the creation of an infrastructure that delivers the created content to the content consumers.
As a result of these and other benefits, many different CDNs are in operation today. Edgecast, Akamai, Limelight, and CDNetworks are some examples of operating CDNs. Each of the CDNs today operates independently of one another. However, this independent operational model is less than ideal for the CDNs and the customers of the CDNs. The CDNs directly compete with one another to offer the same intrinsic services. To do so, the CDNs duplicate capacity and infrastructure where other CDNs have already deployed capacity and infrastructure. The independent operational model also affects customers because a first CDN may optimally deliver content to a first region and a second CDN may optimally deliver content to a second region and a customer operating in both the first and second regions is forced to choose between the two CDNs or is forced to incur additional costs in obtaining services of both CDNs.
CDN federation is advocated by EdgeCast Networks Inc. of Santa Monica, Calif. as a way to address these existing shortcomings and also as a way to provide dynamic CDN scalability, provide a larger global CDN footprint, and increase utilization of a CDN operator's capacity by making some or all of that capacity available to multiple CDN service providers who then, in turn, can realize advantages of a CDN without the need to develop the optimized software and without the need to deploy the infrastructure necessary for a CDN. It is envisioned that CDNs participating in the federation can exchange capacity with one another such that CDNs with excess capacity can avoid the sunk costs associated with capacity going unused by selling that capacity to CDNs that are in need of additional capacity. The capacity sold by a CDN seller can then be configured and used by a CDN buyer to deploy at least one of its customer's configuration to the acquired capacity of the CDN seller. In this manner, a customer's configuration can be deployed from a native CDN to a foreign CDN or the customer's configuration can be simultaneously deployed across capacity of two or more independently operated CDNs. It is further envisioned that participants in the federation can continue to independently manage and operate their networks with minimal change required to participate in the federation.
The CDN interoperation envisioned for the federation introduces issues and complexities that are not readily addressable with existing systems of the federation participants. In many cases, the software and hardware of the CDNs envisioned for the federation are highly customized and proprietary. As some examples, the CDNs internally use identifiers, formats, commands, and protocols that are incompatible with those of other CDNs.
Accordingly, to enable the envisioned federation, systems and methods are needed to permit intercommunication between the independently operated CDNs. Intercommunication in the context of the federation relates to the ability to address capacity across different federation participants, deploy customer configurations across servers of different federation participants, route requests and traffic across configurations that have been deployed to servers of different federation participants, issue commands that invoke actions across the federation, and monitor configurations that have been deployed to servers of different federation participants. Specifically, there is a need to provide systems and methods with which commands such as loads and purges are invoked across the federation irrespective of which servers of which federation participants the commands target.